home *** CD-ROM | disk | FTP | other *** search
- Path: bloom-beacon.mit.edu!hookup!news.moneng.mei.com!howland.reston.ans.net!pipex!pipex!not-for-mail
- From: tim@pipex.net (Tim Goodwin)
- Newsgroups: comp.mail.mime,comp.answers,news.answers
- Subject: comp.mail.mime frequently asked questions list (FAQ) (3/3)
- Supersedes: <mime-faq3_760907132@pipex.net>
- Followup-To: comp.mail.mime
- Date: 21 Mar 1994 19:52:15 -0000
- Organization: Pipex Ltd., 216 Science Park, Cambridge CB4 4WA, England
- Lines: 338
- Approved: news-answers-request@MIT.Edu
- Expires: 14 May 1994 19:51:54 GMT
- Message-ID: <mime-faq3_764279514@pipex.net>
- References: <mime-faq1_764279514@pipex.net>
- NNTP-Posting-Host: tank.pipex.net
- Mime-Version: 1.0
- Content-Type: message/partial; number=3; total=3; id="<mime_764279514@pipex.net>"
- Content-Transfer-Encoding: 7bit
- Summary: This posting contains answers to some of the Frequently Asked
- Questions about MIME (Multipurpose Internet Mail Extensions).
- Please read it before posting a question to comp.mail.mime.
- Xref: bloom-beacon.mit.edu comp.mail.mime:2932 comp.answers:4276 news.answers:16702
-
- Archive-Name: mail/mime-faq/part3
- Last-modified: 1994/02/10
- Version: 3.4
-
-
- comp.mail.mime frequently asked questions list (FAQ) (3/3)
-
- Part III -- Advanced Topics
-
- This is part III of a Frequently Asked Questions document about MIME, the
- multipurpose and multi-media standard for Internet mail.
-
- Part I covers frequently asked questions.
-
- Part II is a listing of MIME products.
-
- Part III covers advanced topics.
-
-
- 10 Information
-
- 10.1 MIME-relevant RFCs and other standards
-
- The RFCs mentioned here are mainly relevant to people building MIME
- software. As an end user, if your mail system is nice to you, you
- won't really have to know very much about these things.
-
- RFC and Internet-Drafts are available by anonymous FTP from any decent
- archive site. If you're really stuck, try
-
- FTP: ds.internic.net:rfc/*
- FTP: ds.internic.net:internet-drafts/*
-
- MIME is defined in RFC 1521 (MIME Mechanisms for Specifying and
- Describing the Format of Internet Message Bodies) and RFC 1522
- (Representation of Non-ASCII Text in Internet Message Headers).
-
- These are Internet standards-track protocols. For the full
- implications of this, see RFC 1540 (IAB Official Protocol Standards).
- Here is their current status.
-
- 1521: Draft Elective Standard
- 1522: Draft Elective Standard
-
- These two RFCs do not fully define MIME. For one thing, they are
- based on RFC 822 (Standard for the format of ARPA Internet text
- messages), as revised by RFC 1123 (Requirements for Internet hosts -
- application and support) and must be read in conjunction with these.
-
- For another, they are extensible. See 10.2 for a complete list of
- registered subtypes.
-
- There are a whole lot of other RFCs that deal with email, including
- these.
-
- IAB standards-track RFCs
-
- 1502 X.400 Use of Extended Character Sets
- 1496 Rules for Downgrading Messages from X.400(88) to X.400(84)
- when MIME Content-Types are Present in the Messages
- 1495 Mapping between X.400 and RFC-822 Message Bodies
- 1494 Equivalences between 1988 X.400 and RFC-922 Message Bodies
- 1427 SMTP Service Extension for Message Size Declaration.
- 1426 SMTP Service Extension for 8bit-MIMEtransport.
- 1425 SMTP Service Extensions.
- 1424 Privacy Enhancement for Internet Electronic Mail: Part IV.
- 1423 Privacy Enhancement for Internet Electronic Mail: Part III.
- 1422 Privacy Enhancement for Internet Electronic Mail: Part II.
- 1421 Privacy Enhancement for Internet Electronic Mail: Part I.
- 1327 Mapping between X.400(1988)/ISO 10021 and RFC 822.
- 1314 File format for the exchange of images in the Internet.
-
- Other RFCs (Informational, Experimental, or Historical)
-
- 1489 Registration of a Cyrillic Character Set.
- 1468 Japanese Character Encoding for Internet Messages.
- 1456 Conventions for Encoding the Vietnamese Language.
- 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME.
- 1357 Format for emailing bibliographic records.
- 1345 Character Mnemonics & Character Sets.
- 1344 Implications of MIME for Internet mail gateways.
- 1343 User agent configuration mechanism for multimedia mail format
- information.
- 1339 Remote mail checking protocol.
- 1321 MD5 Message-Digest algorithm.
- 1225 Post Office Protocol: Version 3.
- 1211 Problems with the maintenance of large mailing lists.
- 1176 Interactive Mail Access Protocol: Version 2.
- 1197 Using ODA for translating multimedia information.
- 1154 Encoding header field for internet messages.
- 1153 Digest message format.
- 1049 Content-type header field for Internet messages.
- 1036 Standard for interchange of USENET messages.
- 934 Proposed standard for message encapsulation.
- 807 Multimedia mail meeting notes.
-
-
- 10.2 List of registered MIME types
-
- A list of registered MIME types is available from
-
- FTP: isi.edu:in-notes/media-types/media-types
-
- This is the latest version.
-
- Type Subtype Description Reference
- ---- ------- ----------- ---------
- text plain [169,NSB]
- richtext [169,NSB]
- tab-separated-values [Paul Lindner]
-
- multipart mixed [169,NSB]
- alternative [169,NSB]
- digest [169,NSB]
- parallel [169,NSB]
- appledouble [MacMime,Patrik Faltstrom]
- header-set [Dave Crocker]
-
- message rfc822 [169,NSB]
- partial [169,NSB]
- external-body [169,NSB]
- news [RFC 1036, Henry Spencer]
-
- application octet-stream [169,NSB]
- postscript [169,NSB]
- oda [169,NSB]
- atomicmail [atomicmail,NSB]
- andrew-inset [andrew-inset,NSB]
- slate [slate,terry crowley]
- wita [Wang Info Transfer,Larry Campbell]
- dec-dx [Digital Doc Trans, Larry Campbell]
- dca-rft [IBM Doc Content Arch, Larry Campbell]
- activemessage [Ehud Shapiro]
- rtf [Paul Lindner]
- applefile [MacMime,Patrik Faltstrom]
- mac-binhex40 [MacMime,Patrik Faltstrom]
- news-message-id [RFC 1036, Henry Spencer]
- news-transmission [RFC 1036, Henry Spencer]
- wordperfect5.1 [Paul Lindner]
- pdf [Paul Lindner]
- zip [Paul Lindner]
- macwriteii [Paul Lindner]
- msword [Paul Lindner]
- remote-printing [RFC1486,MTR]
-
- image jpeg [169,NSB]
- gif [169,NSB]
- ief Image Exchange Format [RFC-1314]
- tiff Tag Image File Format [MTR]
-
- audio basic [169,NSB]
-
- video mpeg [169,NSB]
- quicktime [Paul Lindner]
-
- Each <type> has a directory
-
- FTP: isi.edu:in-notes/media-types/<type>
-
- containing the definitions of its subtypes.
-
-
- 10.3 Internet Engineering Task Force (IETF) working groups
-
- The IETF working group on Privacy-Enhanced Mail (PEM) has developed
- extensions that permit confidentiality, authentication, and integrity to
- be provided in a manner backwards compatible with RFC-821 and RFC-822
- (see 3.4). Work is underway to align PEM and MIME which will provide
- real security to MIME email.
-
- The IETF MIME working group is not actively considering significant
- changes to the specifications. However the WG still exists as a forum
- for MIME developers, as a home for interpretation questions, and to
- handle any problems or ambiguities that might arise in MIME.
-
-
- 11 Developers' FAQs
-
- 11.1 How can I register a new MIME type?
-
- The procedures for registering new content types, character set
- values, access types, and conversions parameters with IANA (the
- Internet Assigned Numbers Authority) are documented in RFC 1521.
-
-
- 11.2 What's ESMTP, and how does it affect MIME?
-
- ESMTP (Extended Simple Mail Transfer Protocol) is a mechanism by which
- extensions to "traditional" (RFC 821) SMTP can be negotiated by client
- and server. The mechanism (RFC 1425) is open-ended; so far two
- extensions have been defined.
-
- Message size declaration (RFC 1427) offers a graceful way for servers
- to limit the size of message they are prepared to accept. (With SMTP,
- the only possibility is for the server to discard the message after it
- has been sent in its entirety. There is no way for the client to know
- that it was the size of the message that caused the problem.)
-
- When a message is returned to the user as being too large to deliver,
- one possible approach might be to fragment the message using the MIME
- Message/Partial mechanism, and resubmit it.
-
- Depending on the exact reason for the "too large" rejection, this may
- or may not be a good idea. For example, the limitation may reflect
- the recipient's disk quota, in which case the fragmented message will
- not be fully deliverable either.
-
- The possibility of fragmentation should, therefore, be left to the
- user's discretion (not performed automatically by the SMTP client).
-
- 8bit-MIMEtransport (RFC 1426) opens up the possibility of sending 8bit
- data in mail messages, without having to use base64, quoted-printable,
- or another encoding, and without the breakage that can result from
- sending 8bit data to an unsuspecting RFC 821 SMTP server. RFC 1428
- (Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME)
- discusses some of the implications of this.
-
-
- 11.3 Where can I get some sample MIME messages?
-
- FTP: thumper.bellcore.com:pub/nsb/samples/*
-
-
- 11.4 Wouldn't MIME be better if it did <foo>?
-
- This question is asked for various values of <foo>. Perhaps the most
- common is "multilevel encodings": see the next question. There are
- a couple general points that apply to all <foo>.
-
- 1. Please remember that MIME is the result of a lot of work by a lot
- of people, over a long time (look at the Acknowledgements section of
- RFC 1521). A great many ideas, probably including yours, were
- considered. In many cases, there were conflicting goals, such as
- simplicity and interoperability on the one hand, and power and
- flexibility on the other.
-
- 2. If you really think you've got an original idea which would improve
- MIME, the correct place to pursue it is not this newsgroup, but the
- working group mailing list (having first read the archives, to check
- that it really is new). Yes, this is going to be a lot more work than
- posting a news article.
-
-
- 11.5 So what about multilevel encodings?
-
- MIME uses a two-level encoding scheme. The original object (for
- example, a picture, or a text document) is encoded using a well
- defined mechanism appropriate to that object (perhaps GIF for the
- picture, and text/enriched for the document). Then a second encoding
- is used to ensure that the first encoding can be transmitted intact
- (probably base64 for the GIF, and quoted printable for the
- text/enriched document).
-
- Note that there is a very small number of the second encodings (five,
- but three of these are simply indications of what kind of data an
- unencoded body part contains), and it is not expected that there will
- be many more in the foreseeable future.
-
- The multilevel encodings idea is for a more generalized MIME-like
- encoding mechanism that could indicate many arbitrary transformations
- of the original object. For example,
-
- Content-Type: application/tar; conversions="encrypt,compress,uuencode"
-
- might indicate a UNIX tar file that had been encrypted, then
- compressed, then uuencoded. (This is a fictitious example of how MIME
- might have worked; it's not legal MIME. Don't worry if you've never
- heard of some of these transformations.)
-
- This may look like an attractive scheme at first, but it has a number
- of problems.
-
- 1. If you've been brought up on UNIX and command pipelines, the
- implementation of such a scheme seems trivial. Surely any half-decent
- machine can do something similar? Unfortunately, this turns out to be
- true only for a very restricted definition of "half-decent". In
- practice, it would be awfully difficult to implement this on a lot of
- systems. Probably even more systems would not allow new
- transformations to be just "slotted in", and would require
- recompilation or reshipping whenever a new one came along.
-
- 2. Each successive transformation reduces the size of the audience who
- can successfully decode the message. Every MIME mailer must be able
- to decode base64 and quoted-printable, so it's guaranteed that you can
- at least get back to the raw data. What if, in the above example, I
- have tar, decrypt, uudecode, but no uncompressor?
-
- 3. Such a scheme does not increase the scope of the framework defined
- by MIME. If uuencoded, compressed, encrypted tar files are useful
- things to sling around, it is entirely possible to define a new MIME
- type (presumably a subtype of application) to handle them.
-
-
- 11.6 Why doesn't MIME include a mechanism for compression?
-
- Compression is a difficult area. It was considered by the working
- group, but no consensus was reached. There is still work going on in
- this area: there may someday be a compressed-64 encoding.
-
- Most compression algorithms have one of more of these undesirable
- properties: they are covered by patent, they require the ability to
- treat the input as a stream of bits, they use a large data space. The
- chances of finding a truly interoperable compression algorithm are
- therefore rather slim.
-
- It is worth noting that most or all of the image and video subtypes
- (including GIF, JPEG, TIFF, and MPEG) define their own compression
- schemes.
-
-
- 12 Acknowledgements
-
- Many people have contributed to this document.
-
- They include:
-
- Alan Robiette, Alec Henderson, Axel Boldt, Carlyn Lowery, Chris Pepper,
- Christophe Wolfhugel, Christopher Davis, Craig Huckabee, Daniel
- Fandrich, Daniel Glazman, Dave Curry, Dave Lacey, David Collier-Brown,
- David Miller, Ed Anselmo, Edward Vielmetti, Erik van der Poel, Harald
- Alvestrand, Ian Hoyle, James Ford, Jason Beyer, Jay Weber, Jerry Sweet,
- Joe Ilacqua, Joergen Haegg, John Gardiner Myers, John Martin, John
- Romine, Joyce Reynolds, Keith Moore, Larry Salomon Jr, Lars-Gunnar
- Olsson, Luc Rooijakkers, Marc VanHeyningen, Mark Crispin, Mark Grand,
- Marshall Rose, Martin Wendel, Masanobu Umeda, Michael Parson, Michael
- Urban, Nathaniel Borenstein, Ned Freed, Niklas Agren, Pat Farrell, Paul
- Eggert, Piero Serini, Quentin Smart, Ran Atkinson, Ray Langford, Rich
- Ragan, Rick Troth, Ron Barak, Steve Dorner, Steve Hole, Stuart Lynne,
- Susan Straub, Syd Weinstein, Tim Kehres, Tommy Wallo, Yehavi Bourvine.
-
- If I've left your name off, please accept my apologies. Drop me a
- note and I'll include it for next time.
-
- Thanks also to Jonathan Kamens, for coordinating the *.answers groups,
- and for his post_faq program which brought you this FAQ.
-
-
- End of Part III
-